A scripted control system for autonomous hardware-timed experiments 

P. T. Starkey[^]c. J. Billington j^J S. P. Johnstone, M. Jasperse, K. Helmerson, L. D. Turner, and R. P. Anderson 

School of Physics, Monash University, Victoria 3800, Australia. 

(Dated: 15 April 2013) 

We present the labscript suite, an open-source experiment control system for automating shot-based exper- 
iments and their analysis. Experiments are composed as Python code, which is used to produce low-level 
hardware instructions. They are queued up and executed on the hardware in real time, synchronized by a 
pseudoclock. Experiment parameters are manipulated graphically, and analysis routines are run as new data 
is acquired. With this system, we can easily automate exploration of parameter spaces, including closed-loop 
optimization. 



I. INTRODUCTION 

Modern experiments in quantum science demand flex- 
ible, autonomous control of heterogeneous hardware. 
Many such experiment are shot-based: a single ex- 
periment shot comprises analog, digital and radiofre- 
quency (rf) outputs operating under precise timing, 
as well as synchronized camera exposures and volt- 
age measurements. Bose-Einstein condensation (BEC) 
experiments^, for example, require a timing resolution 
down to a few hundred nanoseconds, and may last for up 
to a minute. Output must therefore be hardware timed, 
requiring devices be programmed with instructions in ad- 
vance of an experiment shot. Most measurements of in- 
terest require numerous shots, to build up statistics, or 
to observe the response of the system to varying param- 
eters. Such repetition is common to experiments em- 
ploying cold quantum gases or trapped ions for preci- 
sion metrology 2 , quantum computatiorP, and quantum 
simulation 4 . 

Individual shots are typically complex, requiring the 
coordination of many devices. This coordination is the 
role of a control system. A good control system should 
automate the programming of devices based on a high- 
level description of the experiment logicP. It should han- 
dle the repetition of shots and automated variation of ex- 
periment parameters, the increasingly complex demands 
of which cannot be rapidly, robustly and continuously 
met by human operators. It should automate analysis, 
leading to the prospect of closed-loop control: the results 
of analysis influencing subsequent experiment shots. Ap- 
plications of such closed-loop control include autonomous 
algorithmic optimization of parameters, and automatic 
recalibration in response to environmental drifts. 

Most existing control systems take one of two ap- 
proaches for providing a human interface to programming 
hardware. One is text-based, in which experiments are 
written using a general purpose programming language 6 . 
In the other, experiments are instead described graphi- 
cally using a custom user interface^J] The text-based 
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approach natively offers the advantages of a program- 
ming language, particularly control- flow tools such as 
conditional statements, loops and functions. Its disad- 
vantage is that frequently varied settings and parameters 
may be hidden in hundreds of lines of code. Conversely, 
the graphical-user-interface (GUI) approach makes ex- 
periment parameters more accessible to the user, but 
features providing for complex experiment logic must be 
anticipated and implemented specificall y 10 1 11 1 . 

The two approaches need not be mutually exclusive: 
by separating experiment parameters from experiment 
logic, parame ters c an be manipulated graphically and 
logic textuall y 12 l 13 i We contend that by using a high- 
level programming language with appropriate hardware 
abstraction, text-based control can be more comprehen- 
sible to a newcomer than an equivalent graphical repre- 
sentation of hardware instructions. 

We present the labscript suite which utilizes a hybrid 
text-and-GUI approach for control and builds on previ- 
ous work by addressing the need for autonomous con- 
trol, analysis and optimization. Hardware control is ab- 
stracted, providing an identical software interface to de- 
vices of a common type. Graphical interfaces are dynam- 
ically generated based on the current hardware set in use. 
Analysis is an integral part of the control system, with 
user-written analysis routines run automatically on new 
data. Finally, analysis results can modify subsequent ex- 
periment shots, closing the feedback loop on analysis and 
control. 



II. AN OVERVIEW OF THE LABSCRIPT SUITE 

The labscript suite comprises several programs, each 
performing one main function; the flow of data between 
programs is shown in Fig. [I] Each experiment shot is 
associated with a single file: each program writes to and 
reads from this file as required before passing it on to 
the next program. Programs may be run on separate 
computers, communicating over the network using the 
ZeroMQ messaging library 14 , exchanging references to 
the experiment file. 

We use the Hierarchical Data Format (HDF version 
5)P^ which provides cross-platform storage of large scien- 
tific datasets. Exploiting the extensibility of HDF, each 
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FIG. 1. Each experiment shot comprises three stages: preparation, execution and analysis. Arrows indicate how the HDF file 
for an experiment shot passes between software components of the labscript suite. Only the shot execution stage is coupled to 
hardware timing, allowing new shots to be created and queued while others are running. Similarly, analysis can be performed 
on executed shots at any time. 



file is a complete description of the experiment shot. The 
HDF file begins life containing only experiment parame- 
ters. As it is passed between components of the labscript 
suite, the file grows to contain the hardware instructions, 
acquired data and analysis results. Metadata is also 
stored including user-written scripts and version control 
information. This maintains a comprehensive record of 
the experiment shot for post-hoc analysis, reproducibility 
and publication preparation. 

Attempts to standardize laboratory device program- 
ming have largely failed, with only a minority of de- 
vices conforming to standards such as SCP1 16 . This calls 
for abstraction to shield the user from low-level interac- 
tion. We have cre ated a software library for PythonP^L^, 
labscript (Sec. IV), which provides a common inter- 
face for commanding output and measurements from de- 
vices. The user writes the experiment logic in Python, 
and labscript generates the required hardware instruc- 
tions, including a clocking signal for timing (Sec. |III| ). 

The labscript suite separates experiment logic (writ- 
ten in Python) from experiment parameters, which are 
manipulated in a GUI. The GUI, runmanager (Sec. |V|), 
creates the HDF file for the experiment shot and stores 
the parameters within. If a parameter is a list of values, 
rather than a single value, runmanager creates an HDF 
file (a prospective shot) for each value. If lists are entered 
for more than one parameter, runmanager creates a file 
for each point in the resulting parameter space. 

For each shot, labscript inserts the parameters from 
the HDF file into the experiment logic, compiles hard- 
ware instructions for each device, and writes them to the 
same file, r unma nager sends the compiled HDF files to 
BLACS (Sec. VI) which places them in a queue. BLACS 
interfaces with hardware devices either directl y, or via 
secondary control programs such as BIAS (Sec. VII). It 
programs the hardware and triggers the experiment shot 
to begin. The experiment then proceeds under hardware- 



timed control. 

Once the experiment shot has finished, acquired data 
such as voltage time-series and images are added to the 
HDF file. BLACS then passes the file to a dedicated anal- 
ysis system, lyse (Sec. VIII). lyse coordinates the ex- 



ecution of analysis routines, which are Python scripts 
written by the user. These scripts may analyze individ- 
ual shots or a sequence of shots as a whole. This fa- 
cilitates autonomous analysis of results from parameter 
space scans, as experiment shots are completed. 

The labscript software library can be applied to auto- 
matically generate shots based on the results of analysis. 
We have used this to implement a closed-loop optimiza- 
tion system, mise (Sec. IX). 



III. PSEUDOCLOCK 

A typical BEC experiment requires precise timing over 
a large range of time scales 1 . There are periods dur- 
ing which magnetic fields or laser intensities, for exam- 
ple, may change with sub-microsecond resolution. Con- 
versely, there are periods during which no devices change 
their output for several seconds, e.g. loading a magneto- 
optical trap (MOT). To ensure accurate output during 
the rapid changes, hardware devices must be preloaded 
with a set of instructions that can be stepped through by 
a clock once the experiment begins. Stepping through in- 
structions at a constant rate requires repetitive instruc- 
tions during the more inactive periods. As many de- 
vices only support a limited number of instructions, a 
constant-rate clo ck limit s the maximum sample rate. A 
common solution ^ * 9 * 11 * 12 * is a variable frequency master 
clock, or pseudoclock, which steps through instructions 
only when a clocked device needs to update an output 
(see Fig. [2}. This removes the need for redundant in- 
structions. 
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FIG. 2. An example of digital and analog voltage outputs generated by the labscript code in Fig. [3] The pseudoclock (lower 
trace) ticks when a digital output must change, or at the requested sample rate for time- varying analog outputs (upper two 
traces). Dashed vertical lines indicate a change in the pseudoclock frequency. When multiple analog outputs are varying at 
the same time (shaded region), the pseudoclock ticks at the highest of their sampling rates. 



All devices sharing a pseudoclock must have an instruc- 
tion when any one of their outputs changes. This can lead 
to redundant instructions if only some of the devices are 
changing at a given time. The instruction limitations of 
one device may then limit another, e.g. some devices hold 
only a few thousand instructions in their internal mem- 
ory, whereas others are limited only by the RAM of the 
host computer refilling their buffers. To solve this prob- 
lem, we employ multiple pseudoclocks, assigning devices 
of similar memory limitations to the same clock. At the 
beginning of a shot, the software starts one pseudoclock 
(the master clock), which then triggers other clocks. 

To be a useful pseudoclock, a device must be able to de- 
terministically generate arbitrary digital signals, be hard- 
ware triggerable, and hold enough instructions for the re- 
quired experiment. We currently use two pseudoclocks: 
the SpinCore PulseBlaster DDS-II-300-AWG, a commer- 
cial FPGA-based device with DDS and digital TTL out- 
puts; and the PineBlaster, a microcontroller-based device 
developed in- house. Both devices are externally refer- 
enced to a stable 10 MHz source. 

The PineBlaster is a low-cost device using commodity 
hardware, based on the Arduino-like Digilent ChipKIT 
Max32 microcontroller prototyping boarcPH The board 
is flashed with a program that accepts clock instructions 
over USB and executes them with deterministic timing. 
It is capable of clocking at up to 10 MHz (100 ns between 
rising edges) with a resolution of 25 ns. The PineBlaster 
needs one instruction for each change in clock rate (see 
Fig. [2]) and supports up to 15,000 instructions. 

labscript provides support for adding new pseudo- 
clocks. It uses an intermediate format for storing tim- 
ing instructions; implementing a new pseudoclock entails 
translating them into the required format for the hard- 
ware. 



Some experiments require the time between instruc- 
tions to be determined during a shot. This can be 
achieved by pausing the pseudoclocks until some condi- 
tion is met. A common example^Mll is waiting for a suffi- 
cient level of fluorescence from a loading MOT. Both the 
PulseBlaster and the PineBlaster support wait instruc- 
tions, which pause output until resumed by a trigger. 
These instructions, when used in tandem with devices 
such as voltage comparators, can command the experi- 
ment to wait for events of interest. 



IV. THE LABSCRIPT LIBRARY 

We have created a Python software library, labscript, 
for defining experiment logic, labscript provides hard- 
ware abstraction, a common interface to control hetero- 
geneous hardware. For example, the DigitalOut class 
provides go_high(t) and go_low(t) functions to set the 
state of a digital output at time t. The user calls these 
functions without regard to the underlying device, its 
method of programming, or the state of other digital out- 
puts connected to the same device. Based on an exper- 
iment script containing such function calls, labscript 
automatically generates instructions for output and mea- 
surement devices as well as pseudoclocks. The auto- 
matic generation of pseudoclock instructions saves the 
user from dividing overlapping function ramps into seg- 
ments (Fig [2|, or manually interpolating output values 
when a new time point is created on another channel. 

An experiment script consists of two parts: a connec- 
tion table (Fig [31(a)), and code defining the logic of the 
experiment (Figj3](b)). The connection table provides a 
complete description of devices that are required for the 
experiment and how they are connected, labscript ere- 
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(a) # Device definitions 

PulseBlaster (name= ' pseudoclock_0 ' , board_number=0) 

NI_PCIe_63 63 (name= ' ni_card_0 ' , parent_device=pseudoclock_0 , clock_type= ' f ast clock', 
MAX_name=' ni_pcie_63 63_0 ' , clock_terminal= ' /ni_pcie_6363_0/PFlO ' ) 

# Channel definitions 

Shutter (name='laser_shutter' , parent_device=ni_card_0 , connection= ' port0/linel3 ' ) 

AnalogOut (name= ' quadrupole_f ield ' , parent_device=ni_card_0 , connection= ' aoO 1 ) 

AnalogOut (name= ' bias_x_f ield ' , parent_device=ni_card_0 , connection= ' aol ' ) 



(b) # Experiment logic 
start () 
t = 



# first laser pulse at t = 1 second 
t += 1; laser_shutter . open (t) 
t += 0.5; laser_shutter . close (t) 
t += 0.4; 



t += quadrupole_f ield . ramp (t , duration=5 f initial=0 f final=3, samplerate=4 ) # samplerate in Hz 

# start ramping the bias field 3 seconds before the quadrupole ramp ends 
bias_x_f ield . ramp (t-3 , duration=l , initial=0 , final=2.731, samplerate=8 ) 

# t is now 6.9s, the end of the quadrupole field ramp 



# second laser pulse 

t += 0.4; laser_shutter . open (t) 

t += 1; bias_x_f ield . constant (t , value=0.0) 

t += 0.5; laser_shutter . close (t) 

t += 2 



# hold bias field at bias_x_f inal_f ield for 2 seconds before finishing shot 
bias_x_f ield . constant (t , value=bias_x_f inal_f ield) 
t += 2 
stop (t) 



FIG. 3. An example labscript file. The connection table (a) defines a pseudoclock and a multifunction DAC object and 
configures three output channels. This is followed by the experiment logic (b) which commands output from these channels 
by name at times specified by the variable t. The experiment logic refers to the parameter bias_x_f inal_f ield which is set in 
runmanager (Sec. [V|. 



ates a set of Python objects based on the connection ta- 
ble, each with associated functions for commanding out- 
put or measurement from devices. The logic of the ex- 
periment is then defined by calling these functions with 
parameters such as time and output value. 

As the experiment script is executable Python code, 
the user has full access to standard Python control flow 
tools, as well as standard and third party Python li- 
braries. Using a high level language such as Python 
spares the user from low-level tasks such as memory 
management!^. User-created functions can be stored in 
modules and imported into other experiment scripts. 
This allows complex experiments to be constructed from 
simple components, whilst maintaining comprehensibil- 
ity, resulting in a gentler learning curve for new students. 
For example, one might define a make_BEC() function 
which contains the logic to form a Bose-Einstein con- 
densate. Whilst students might not fully understand the 
experiment logic to create a BEC, they can focus on sub- 
sequent experiment logic after a BEC is made. We have 
found that text based experiment scripts benefit not just 
from code re-use but also version control, bug tracking, 
and comparison of incremental changes (diffs). 

When the experiment script is run and a timing se- 
quence created, the labscript functions take into ac- 



count hardware limitations and throw error messages if 
these are exceeded. If no errors are found, the hardware 
instruction set for all devices in the connection table are 
written to the HDF file. 

While a text-based definition of experiment logic gives 
a broad overview of the timing sequence, it is not ideal 
for visualizing the device outputs to ensure the exper- 
iment logic is as intended. The hardware instructions 
generated by running experiment scripts are difficult to 
interpret (indeed, labscript was created to mitigate this 
very problem). Our program (runviewer) produces plots 
(similar to Fig|2| of the hardware instructions generated 
by labscript, allowing quick diagnosis of the timing se- 
quence before reaching for the oscilloscope. 



V. SETTING PARAMETERS— RUNMANAGER 

Repeating experiments whilst varying parameters is a 
fundamental part of the scientific method. Anyone who 
has performed a quantum science experiment will be fa- 
miliar with tweaking parameters to find a resonance, cal- 
ibrating a measurement, or acquiring a large amount of 
scientific data prior to publication. The logic of the ex- 
periment does not change every time a parameter is ad- 
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FIG. 4. The runmanager interface for configuring experiment parameters, (a) The experiment logic is specified by the labscript 
file (here trap_atoms.py). HDF files for experiment shots created by runmanager are saved in the output directory, (b) The 
value of experiment parameters ('globals') are specified by Python expressions and may have units. These can be single values 
(i.e. 350 or True), lists or expressions creating lists (as shown for the globals pgc_detuning, pgc_quad, and tof _drop_time). A 
tooltip shows the evaluation of the global. The 'Expansion' column specifies how lists of values are combined to construct a 
parameter space, (c) Globals can be separated into groups for convenience. 



justed, and it is cumbersome to edit numbers in a text 
file for each modification. 

To ameliorate this, labscript experiments can take a 
series of parameters as input. The names and values of 
these parameters are defined in the graphical interface of 
runmanager (Fig. [4]). The values can be any valid Python 
expression (such as 0.74, 1E-3, sin (pi/2), or True) and 
can refer to each other. We call these parameters globals 
because they are available as global variables in experi- 
ment scripts, where they are simply referred to by name. 
For example, these globals might be used to specify the 
duration of a 7r-pulse, the delay between releasing atoms 
from a trap and imaging them, or the field strengths of 
bias magnetic coils. This provides a clean separation be- 
tween code, which defines the nature of the experiment 
(such as creating a BEC with a vortex or performing a 
matter- wave mixing experiment), and parameters that 
modify individual shots. 

The user may enter a list of values for a global, 
such as [1,2,3], or linspace(0, 10, 100) . In this case 
runmanager produces a corresponding list of experiment 
shots: one for each value. If multiple globals are entered 
as lists, runmanager performs a Cartesian product, cre- 
ating one shot for each point in the resulting parameter 
space. Two or more lists can be zipped, in which case 
runmanager iterates over these lists in lock-step when 
producing shots. 

Specifying globals as lists makes it possible to explore 
complicated parameter spaces containing hundreds or 
thousands of shots. For example, one might investigate 



how the temperature of laser cooled atoms varies with 
laser detuning and magnetic field gradient. Taking the 
Cartesian product of ten field strengths and ten detun- 
ings results in a parameter space of one hundred points. 
Thermometry at each point in this parameter space com- 
monly requires multiple shots to characterize the expan- 
sion rate of the atom cloud. A five-shot temperature 
measurement brings the number of shots to five hun- 
dred. Producing these shots amounts to entering three 
lists in runmanager and clicking on the 'engage' button, 
as shown in Fig. [4j runmanager then creates five hun- 
dred HDF files containing the globals for each shot. The 
experiment script is run for each shot, storing hardware 
instructions in each file. The HDF files are then submit- 
ted to BLACS for execution. 



VI. EXPERIMENT EXECUTION— BLACS 

BLACS coordinates input and output through hardware 
devices. These devices can be local, and thus under the 
direct control of BLACS, or connected to a different com- 
puter as p art o f a secondary control program such as 
BIAS (Sec. VII ). BLACS provides both manual control of 
devices (through a GUI) and buffered execution of ex- 
periment shots. 

The GUI for manual control is dynamically generated 
from a lab connection table that describes the current 
configuration of all connected devices. Each device is al- 
located a tab in the interface, containing controls for com- 



I* 



Delete selected 



d BLACS 
File Device Connection Table Help 

Queue running Repeat 

Now running: 20130808T152Q55_trap_atoms_017.h5 

| h0F5 Path 

Ltrap_atorns\2013-Mar\08\20130308T15205S_trap_ai 
£rap_atoms\2013-Mar\08\20l30308T152055_trap_a 
^trap_atoms\2013-Mar\08\20130308T15205S_trap_a 
^trap_atoms\2013-Mar\08\20130308T152055_trap_ai 
\trap_atoms\2013-Mar\08\20130308T152055_trap_a 
k trap_atoms\2013-Mar\08\20130308T152055_trap_a 
^trap_atom5\2013-Mar\08\20130308T152055_trap_a 
£rap_atoms\2013-Mar\08\20130308T15205S_trap_ai 
!.trap_atoms\2013-Mar\08\201303O8T152055_trap_a 
£rap_atoms\2013-Mar\08\20130308T152055_trap_a 
ll trap_atorns\2013-Mar\08\20130308T1520SS_trap_a 
( ,trap_atoms\2013-Mar\08\20l30308T152055_trap_a 
\trap_atoms\2013-Mar\08\20130308T15205S_trap_ai 
( ,trap_atoms\2013-Mar\08\20130308T152055_trap_a 
\trap_atoms\2013-Mar\08\20130308T15205S_trap_a 
itrap_atoms\2013-fviar\0S\20' 3030ST' 52055_trap_ai 
\tra p_a toms\20 1 3- Mar\08\2 1 3030ST1 5 2 05 5_tra p_a 
\trap_atoms\2013-Mar\08\20130308T1520SS_trap_ai 
,trap_atoms\2013-Mar\08\20130303T152055_trap_a 
!,trap_atoms\2013-Mar\08\20130308T1520S5_trap_ai 
\t ra p_a to m s\2 '-. 3 - M a r \0 S \ .2 ' 3030ST' 5205 5_tra p_a i 
>,trap_atoms\2013-Mar\08\20130308T152055_trap_a 
\trap_atoms\2013-Mar\08\20130308T152055_trap_ai 
^trap_atoms\2013-Mar\08\20130308T152055_trap_a 



(l trap_atoms\2013-Mar\08\20130308T152055_trap_a 



l-ran fl|-c>m<;\?ni 3-fvlflr\f)R\?m ^03nSTi 5705S fran 



:orns_018.h5 
_0'9.h5 
:oms_020.h5 
;oms_021.h5 
:oms_022.h5 
:orns_023.h5 
:oms_024.h5 
:oms_025.h5 
_026.h5 
:oms_027.h5 
:orns_028.h5 
:oms_029.h5 
:oms_030.h5 
:oms_031.h5 
:oms_032.h5 
:oms_033.h5 
:oms_034.h5 
:oms_035.h5 
:oms_036.h5 
:oms_037.h5 
:oms_038.h5 
:oms_039.h5 
:oms_040.h5 
:oms_041.h5 



a 



:oms_042.h5 



1-laLaJ 

S pulseblaster.O ^ novatechdds9m_o" t novatechdds9m_1 <^ pulseblaster_1 <^ red.camera & camera 



novatechddi9m_0 - Pert: com 10 



^ Smart programming in use. 
□ Force fresh reprogram 



Channel - Rb Central MOT 



Frequency [81 500000,0 |^)|hz C~| Amplitude: [643 |C](Arb. ] Phase: [ 0,00 Degrees C j 



Channel 1 - Rb Central Repump 
Frequency [950Q0Q00.0 |v|hz ] Amplitude: [750 j C j[ Arb, 5"j Phase: [ 0,00 ~[c|| Degrees C ] 



Channel 2 -Rb Source Repump 
Frequency [96000000,0 |^][hz C ] Amplitude: [750 |y)[Arb. \ Phase: [ 0,00 ~[C f Degrees 



Channel 3 - Rb Main Lock 



Frequency 47000000.0 ; Hz Amplitude: 563 Arb. C I Phase: 0.00 ; Degrees 



idle 


I 


<^ ni_pcie_6363_0 


ni_pci_6733_0 j <tf novatechdds9m_2 ] novatechdds9m_3 ] A rfblaster.O ^ 



Analysis 










Send Files 
For analysis 




Analysis server host: 








j bee- krb- analysis 




Server is responding 


Check connectivity 





Analog Outputs 



IE 



A02 

Sorense n Voltag e 

1 0.5500 [~l[v0| 



A03 
dipolejens 



Digital Outs (Port 0) 



DO P0:0 


DOPO:1 


Rb_Central_MOT_gate 


Rb_Cen tral_Repu m p_ga te 


DO P0:2 


DO P03 


Rb_Source_Repump_gate 


pb_1_trigger 


DO P0:4 


DO P0:5 


KJmaging_Repump_Push_gate 


K_MOT_Repump_gate 


DO P0:6 


DO P0:7 


Rb_Optical_Pumping_gate 


K_lmaging_gate 


DO P0:8 


DO P0:9 


Rb_Source_MOT_Sh u tter 


Rb_Push_shutter 



Running... program time: 4.1 s 



(b) 



FIG. 5. The BLACS interface for controlling hardware, (a) The queue of shots submitted via runmanager. (b) The manual 
control interface. Each tab controls one device. Controls for all outputs are automatically generated and are named based on 
the BLACS connection table. 



manding output when in manual control mode (Fig. [5]). 

Upon submission to BLACS, HDF files containing 
hardware instructions are checked for validity and placed 
in a queue. The queue can be reordered, paused or put on 
repeat. The validity check compares the connection table 
of each shot to the lab connection table, rejecting those 
with incompatible hardware. This prevents unintended 
device output that would produce nonsensical results and 
possibly damage equipment. 

BLACS takes the first experiment in the queue, coordi- 
nates hardware programming and sends a start trigger to 
the master pseudoclock. The experiment then proceeds 
under hardware timing. At the end of a shot, BLACS coor- 
dinates saving data acquired by devices to the HDF file, 
and returns to manual control mode. Each GUI control 
is updated to the final values of the shot, maintaining 
output continuity. 

Laboratories are a hostile environment for hardware 
interface libraries. Power cycling of devices and unplug- 
ging of cables are common occurrences. A student trip- 
ping over a USB cable (health and safety implications 
notwithstanding) might be expected to cause an experi- 



ment to fail, however the control system ought to recover 
gracefully when it is plugged back in. Similarly, bugs in 
closed source drivers and libraries are points of failure 
outside of a users control. 

To make our system robust against such hardware and 
software failures, BLACS implements a multiprocess ar- 
chitecture similar to the sandboxed tabs of the Google 
Chrome web browser^. For each device in BLACS, a 
worker process is spawned, which communicates with 
the hardware device. This makes BLACS robust against 
crashes: if one device has a problem it will not affect 
others. If a hardware device becomes unresponsive, or 
the device driver encounters a serious error, its isolation 
in a separate process prevents the GUI and other devices 
from suffering the same fate. 

Should a worker process crash, the user is presented 
with the option of restarting the process, which will 
reload any device libraries it uses. It is worth noting 
that systems implemented in Lab VIEW cannot force li- 
braries to reload, so errors leading to an undefined state 
would only be remedied by restarting the entire control 
system. 




FIG. 6. The BIAS interface displaying a laser cooled atom cloud, (a) Manual controls for loading and capturing images, selecting 
regions of interest and zooming, (b) Computed optical depth (OD) image of the atoms, with a region of interest (white) selected 
for fitting. Multiple regions of interest may be selected for multi-component atom clouds, (c) Atom number and cloud size are 
displayed for immediate feedback. 



The multiprocess architecture naturally provides for si- 
multaneous programming of hardware devices, resulting 
in an increased experiment duty cycle. We have imple- 
mented a smart programming feature on many of our de- 
vices, further decreasing programming time, reprogram- 
ming them only if their instructions have changed since 
the previous shot (on a per-instruction basis when pos- 
sible). Devices with large buffers and slow communica- 
tion (such as the Novatech DDS9m rf synthesizer) benefit 
greatly from this technique. 



VII. IMAGE ACQUISITION— BIAS 

Using secondary control programs to communicate 
with specific devices is desirable when software to do so 
exists and has been debugged, particularly software writ- 
ten in another programming language. BLACS integrates 
such programs into the control flow by sending them HDF 
files containing hardware instructions to program devices 
for execution upon a hardware trigger. BLACS notifies sec- 
ondary control programs that the shot has completed, at 
which point they write any acquired data to the HDF 
file. 

Our camera control and image acquisition system, 
BIAS, is one such program. BIAS is a Lab VIEW appli- 



cation that operates scientific cameras, capturing image 
sequences and performing image processing tasks such 
as background subtraction, saturation correction, opti- 
cal depth calculation and simple 2D fitting. 



Multiple instances of BIAS can be run simultaneously 
to control multiple cameras in one experiment. BIAS can 
also run as a stand-alone program for quick visualization 
of previously captured data or acquire images manually. 
Hardware communication in BIAS is abstracted through 
Lab VIEW's object hierarchy, allowing a camera class to 
be written for any vendor library. 



Lab VIEW provides convenient components for creat- 
ing graphical interfaces, and BIAS displays raw and com- 
puted images as they become available (Fig. [6|. Fit re- 
sults such as atom cloud shape and atom number are 
prominently displayed to detect and diagnose problems 
as they occur. The camera acquisition area and regions of 
interest used to inform fits can be interactively adjusted, 
without needing to interrupt or recreate a currently run- 
ning sequence of shots. Multiple regions of interest can 
be selected and their coordinates saved to the HDF file, 
enabling further analysis. 



:(b) 

| Min temp is 6.74e-06 Kelvin 
I at bb.00 MHz detuning, 
I 0.00 G/cm field gradient. 




FIG. 7. (a) Routines can be selected to analyze single or multiple shots, (b) Terminal output from the analysis routines in (a). 

(c) Table of shots; columns show globals and analysis results. A small subset of columns is displayed here, (d) A fit yielding 
the temperature of laser cooled atoms prepared at a particular field gradient and detuning, (e) The results of the analysis in 

(d) repeated at each point in the parameter space. 



VIII. ANALYSIS— LYSE 

Analysis is a critical part of an autonomous control sys- 
tem. Automated analysis — performed immediately after 
every shot — is often restricted to routines that change in- 
frequently and are applied uniformly once per shot. Ide- 
ally analysis should be flexible as well as autonomous; 
these can be conflicting goals without a unifying analysis 
framework. Our analysis system lyse accommodates col- 
lective analysis of a group of shots and trivial re-analysis 
upon changing or adding routines. 

lyse is a scheduler for user-written analysis routines, 
which are ordinary Python scripts. It provides functions 
for extracting the experiment data and metadata from 
the HDF files and saving analysis results to these files. 
Multiple analysis routines added to lyse execute one af- 
ter the other when a new HDF file is received over the 
network, or on command through the GUI. Plots pro- 
duced by the user's code are updated following every shot 
as new data comes in from the experiment. 

There are two types of routine that lyse can run: 
single-shot, which are run on every shot, and multi-shot, 
which analyze a group of shots together. Analysis of the 
thermometry example in Sec. |V| is shown in Fig. [7| A 
single-shot routine computes size of an atom cloud af- 
ter a fixed expansion time, and a multi-shot routine uses 
these results to determine the expansion rate and thus 
the temperature. The multi-shot routine then plots this 



temperature as a function of laser detuning and magnetic 
field strength. 

Splitting, sorting, plotting and exploring large multidi- 
mensional datasets is cumbersome when directly access- 
ing a set of files. In addition to direct access to the HDF 
files, lyse provides a tabular data structure — a pandas^ 
DataFrame — for multi-shot routines, containing all glob- 
als as set by runmanager, and all single-shot analysis 
results. With pandas and the the standard Python scien- 
tific stack of numpy 22 , scipy 23 , and matplotlib 2 -^, lyse 
provides a powerful environment for analysis^. 

Analysis routines can be run independently of lyse if 
desired. This allows the same framework and analysis 
code to be used for publication preparation. 



IX. OPTIMIZATION— MISE 

Marrying powerful Python tools to shot-based analy- 
sis permits extensibility of the control system, such as 
closed loop optimization of measured quantities. One 
often performs parameter space scans for optimization, 
requiring many shots. This may be tuning a parame- 
ter of an apparatus to enhance its performance, finding 
a resonance of some transition, or some other feature of 
interest. The quantity being optimized is often the result 
of some analysis, e.g. the t emper ature of ultracold atoms 
(mentioned in Sees. [V] and VIII). We have created mise, 
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FIG. 8. The data flow for closed loop optimization. In contrast to Fig. ^ analysis results are used to determine future shots 
automatically. The optimizer mise varies parameters, directly calling labscript to compile new experiment shots. Parameters 
to be optimized are selected by the user in runmanager. lyse reports fitness to mise which is used to create the next generation 
of shots. 



a program that performs automatic optimization of anal- 
ysis results using a genetic algorithm^. A user specifies 
one or more parameters to optimize against a predefined 
figure of merit. Genetic algorithms are resistant to noise, 
making them particularly useful for optimizing experi- 
mental results. 

The data flow of the optimization process follows 
Fig. [8| modifying that shown in Fig. [I] The user speci- 
fies in runmanager one or more parameters to optimize, 
with upper and lower limits for each. An analysis routine 
in lyse reports optimality to mise, which creates shots 
with modified parameters and submits them to BLACS. 

For each parameter being optimized the user also spec- 
ifies a mutation rate. This determines how much the pa- 
rameter is varied per generation of the genetic algorithm: 
the larger the mutation rate, the faster mise will move 
towards the optimum. However a large mutation rate 
limits the precision to which the optimal parameters can 
be determined. 

With this specification of parameters, mise creates a 
population of individuals. Each individual comprises val- 
ues from one point in the optimization parameter space, 
initially chosen at random. An individual may be a sin- 
gle experiment shot, or — when optimizing the result of a 
multi-shot analysis — a sequence of shots. Once the shots 
comprising an individual have executed, the user's analy- 
sis routine computes a fitness, which may be derived from 
any measured quantity, mise uses the reported fitness in 
the genetic algorithm to optimize the specified parame- 
ters. The genetic algorithm used by mise^is a variation 
on Pointed Directed mutation^, in which mutations are 
biased in directions previously shown to be successful. 

The user can specify when to stop the optimization, 
either by manual intervention or by a convergence con- 
dition written into their analysis script. They may also 
'guide' the evolution by adding and deleting individuals 
from the gene pool at any time. 



An example of automated optimization using mise is 
shown in Fig. [9j By preferentially exploring the more 
interesting regions of parameter space, autonomous op- 
timization allows optima to be found in fewer shots. 

mise uses the labscript software library to create 
HDF shot files and submit them to BLACS. Additional 
user-written components could similarly submit shots to 
BLACS if more complex programmatic generation of shots 
is required. 



X. PORTABILITY AND EXTENSIBILITY 

Our software runs on Windows, Linux and OS X, al- 
though BLACS and BIAS compatibility is subject to the 
availability of appropriate hardware drivers. If particular 
devices must be interfaced with a specific computer, op- 
erating system, or programming lan guage , a secondary 
control program (such as BIAS, Sec. VII) can be used. 



The components of the labscript suite communicate with 
each other via data in HDF files, and over the network 
with ZeroMQ sockets. The widespread support of these 
technologies across many platforms^ ensures users are 
not bound to any one operating system or programming 
language. The modular nature of our system allows users 
to replace or supplement any of our programs in their 
choice of language. 

The programs themselves are also written with ex- 
tensibility in mind. Adding new hardware support to 
the labscript suite entails writing a new device class for 
labscript, and a GUI tab for BLACS or a camera class 
for BIAS. Adding analysis routines to lyse amounts to 
writing a Python script to process experiment data. Ex- 
isting library functions and base classes assist such devel- 
opment. The suite has already proved useful in a setting 
distinct from quantum science experiments, automating 
the prototyping of an objective lens, in which the image 
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FIG. 9. A proof-of-principle optimization using mise. mise 
scanned the parameter space described in Sec.[V| searching for 
the coldest point. Each black point represents a temperature 
measurement at a specific field gradient and detuning, with 
the surrounding shading indicating the temperature. Eighty 
points were taken, corresponding to 400 shots. The colder 
region of parameter space is sampled more densely than the 
uniformly-sampled 500 shot scan shown if Fig.|7je). 



of a pinhole was acquired and analysed at 3600 points in 
a plane to determine the field of view^l 

The labscript suite is open-source and freely available 
online 31 . We encourage readers to contact us if they are 
interested in implementing the suite in their laboratory. 
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